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CONFIDENTIAL 



YES, CRYPTOLOG READERS, 

N.S.A. DOES HAVE A 

DATA STANDARDS CENTER 

Mark T. Pattie, Jr., P13D (NDSC) 



B efore I tell you what the NSA Data 

Standards Center (NDSC) does, perhaps 
I should explain why we do it. One 
very good reason is that a previous di- 
rector, VADM Noel Gayler, established the NDSC 
by direction on 1 January 1971. This was later 
formalized by the reissuance in May 1972 of 
NSA Regulation 80-9, the NSA Program for 
Standardization of Data Elements and Related 
Features. 

That would be reason enough to have a 
Center, of course, but there is more. The 
NDSC is really the element responsible for the 
Agency portion of the Department of Defense 
Data Standards Program, which had its begin- 
nings in DoD Directive 5000.11 when that docu- 
ment was published on 7 December 1964. We 
also work closely with the National Bureau of 
Standards, which, under Executive Order 11717 
of 9 May 1973, is responsible for government- 
wide automatic data processing standards. 

By "work closely" I mean that NDSC personnel 
are often in touch with people from the DoD 
and other government agencies on data standards 
matters and they take part in interagency com- 
mittees and working groups as the NSA represen- 
tatives to their meetings. All of this comes 
under NSA Regulation 80-9, which names the 
NDSC as the Agency point of contact for 
federal, DoD, and other external programs or 
efforts for data standardization. One example 
of out committee work is our participation on 
the Data Standards Panel of the Intelligence 
Information Handling Committee of NFIB. 

But even if we did not have the official 
reasons for establishing an NSA Data Standards 
Centers, there would still be the practical 
reasons for it. It must make good sense to 
have data standards instead of Babel and it 
even saves money. Let me illustrate: 

x + y = 7 irr 2 a 2 + b 2 = a 2 

Would it make any difference in working with 
these elements if I were in Germany instead of 
the United States? Or in Italy? Or in Sweden? 
No, for everyone recognizes that these are 
mathematical symbols, which are standard 
around the world. 

How about another example? 

Speed Limit 50 

Well, right away I suspect some readers will 
be uneasy. Here it does make a difference, 



for we have to know if speed is measured in 
miles, in kilometers, or whatever. 

' And so it goes. In oTder to communicate 
with one another, we have to use terms that 
are mutually understandable. That holds true 
whether we are talking about listening to a 
foreign language broadcast or trying to read 
a technical journal for which we have no 
background. In the various sciences there 
is much that is mutually understandable between 
scientists of different nationalities even with 
their language differences, whereas laymen within 
the same country would be at a loss to under- 
stand what is said or written. 

Incidentally, I do not know whether any of 
you are aware of it, but some of those who are 
to all intents and purposes the most handicapped 
in the art of communication — those who cannot 
hear or speak -- have the least trouble with the 
foreign-language barrier. They use symbols -- 
hand signs — which are international standards 
and they can make themselves understood in any 
country where sign language is practiced. The 
hand signs are, in fact, data standards which 
have the same meaning, for the most part, in the 
language of whatever country they happen to be 
in or from. Of course, they might have trouble 
spelling words that are foreign to them but they 
are still better off than most of us who claim 
to have all our faculties. 

A certain amount of data standardization is 
taking place around us all the time. I am re- 
ferring to expressions that once were unique to 
particular parts of the United States at one 
time but which are now becoming rare. Those who 
make studies of such things were able to pin- 
point the birthplace of almost anyone just by 
asking that person to pronounce about ten dif- 
ferent words or to provide the words or terms 
used for certain objects or actions. For 
example, how do you pronounce the following 
words when you are "back home": BUSH/PUSH, 

HOG, GREASY, MERRY/MARY/MARRY. 

Or what do you cook your breakfast eggs in? 

A FRYING PAN/FRY PAN, SKILLET, or SPIDER? And 
what's that big piece of furniture in your 
LIVING R00M/PARL0R? — a SOFA, COUCH, DIVAN, 
or DAVENPORT? How do you pronounce PARK YOUR 
CAR if you're from the Boston area? How do 
you say WATER, wherever you're from? 

Such regional differences are largely 
falling by the wayside, perhaps because 
of the omnipresent TV screen and the nationwide 
distribution of TV programs. Or it might be 
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because people no longer live out their years 
in the areas where they were bom: we are a 
mobile nation. 

Whatever the cause, data standardization 
seems to be with us, whether we like it or not. 
It is a fact of life. I’ll admit that I look 
upon this leveling of the American idiom with 
a certain amount of regret. We are losing some 
of our rich heritage in language and I think 
we will be the poorer for it. 

But the NDSC is not as concerned with the 
exchange of information between individuals 
as it is with the exchange of information be- 
tween machines or between a machine and a ter- 
minal . Here standardization should be a way of 
life but it is not. There are just too many 
examples of Agency elements blithely going 
their own ways regardless of the fact that they 
are duplicating the work of another element, or, 
what is worse, establishing their own standards 
when Agency standards already exist. 

Perhaps 1 should define the term "data 
standards." Although some readers may know 
what the term means, I suspect that many do 
not. By "data standards" we mean consistent, 
agreed-upon names, descriptions, and codes for 
categories of data that will ensure unambiguous 
understanding in data processing and data 
interchange. * 

Note two things in that definition. I did 
not use the word "cryptologic" and I ended with, 
the words "date processing and data inter- 
change." The NDSC is concerned with data stan- 
dards in all fields, both cryptologic and non- 
cryptologic. And, basically, we are trying to 
come to agreements about definitions that will 
make data machine-insertable and machine- 
extractable. 

The latter point is essentially what dis- 
tinguishes data-standards work from that in 
SIGINT terminology, for which the NDSC is also 
responsible. In SIGINT terminology we seek to 
build a SIGINT Terminology Data Base (STDB) and 
glossaries for each cryptologic field. These 
will contain terms that are defined in such a 
manner that they show the currently accepted 
meanings. One way of making the distinction 
between standard terminology and data standards 
is to say that the definitions for the latter 
are more precise than those for standard glos- 
saries. People have less trouble interpreting 
nuances in meaning than do machines. 

Let me give you a simple example of what we 
mean about the difference between the two. If 
we were going to put in a definition for DATE, 
we could use a definition from a general desk 
dictionary for our terminology data base. 

"DATE: 1. A statement or formula affixed 
that specifies the time of execu- 
tion or making (as a letter bear- 
ing the date Z January 1856) . 

2. The point of time at which a 
transaction or event takes place 



or is scheduled to take place." 

{Webster *8 Third New 
International Dictionary ) 

Our Data Standards description is from the 
NSA Manual of Standard Data Elements and 
Related Features (Annex A to USSTD 412) : 

" 00012 ^ 

"DATE: The years, months and days of the 
Gregorian Calendar. 

DATA ITEMS: Represented by 6 digits, 
unspaced, left to right: 

2 for year, 2 for month 
(01-12), 2 for day (01- 
31). (E.g., 15 January 
1969 would be 690115) 

You will note that the Data Standards de- 
scription has measurable factors while the 
Terminology definition does not. 

, The NDSC is not an ivory tower where we 
"do our thing" away and apart from the rest 
of the NSA world. No, we work very closely 
with other people. For instance, every major 
component of the Agency has a representative 
who works with the NDSC staff in identifying, 
researching, and approving data standards and 
SIGINT terms. The Senior Data Representatives 
and Senior Terminology Representatives, in 
turn, work with other contacts at lower eche- 
lons in their own organizations in the pro- 
posing and coordinating phases. We may meet 
with the SDRs or the STRs as a group or as 
individuals, depending on the problem of the - 

The name "Data Standards Center" itself is 
something of a misnomer, for the NDSC is deeply 
involved in more than just data standards for 
machine processing of information. In the ter- 
minology program, people working on the develop- 
ment of the SIGINT Terminology Data Base 
provide guidance on the development and 
use of ternis for SIGINT concepts and their ac- 
companying definitions, maintain a central col- 
lection of reference materials on SIGINT terras, 
and develop a common glossary format for SIGINT 
glossaries published as appendices to USSID 412. 
Our SIGINT terminology program is unique within 
the Intelligence Community. 

In the creation of SIGINT glossaries the 
NDSC terminology people work closely with the 
appropriate terminology panels to develop the 
necessary documentation. The Center, working 
with the Traffic Analysis Terminology Panel, 
developed a draft TA Glossary which is now being 
coordinated with certain elements and our people 
are working with the Signals Collection Termi- 
nology Panel on a draft glossary for that field. 
Terminology personnel are also working with T 
personnel on a Telecommunications Glossary and 
with the TEBAC people on a Telemetry Analysis 
Glossary. In the near future we plan to start 
work on a Data Processing Glossary, while those 
for other cryptologic fields and an interdis- 
ciplinary glossary will be developed as time 
and resources permit. 
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One person concentrates on Multiple Use 
standards — those that are essentially non- 
cryptolpgic, like personnel or budget standards. 
The work involves coordination and many meet- 
ings with people outside the Agency — from the 
Civil Service Commission and the U.S. Air 
Force, for example. Inside NSA our Multiple 
Use expert wbtks mostly with personnel from E, 
L, M, N, or T, but the problems may be of such 
k nature that they concern the entire Agency. 

The NSA Data Standards Center has developed 
a centralized file, of d ata elements/data field 
definitions. This file J I serves 

as a repository of al l the published standards 
for SIGINT activities 

plus other data elements that are being used in 
DPO files and elsewhere without being standards. 
This file will help us to identify data ele- 
ments that are eligible to be proposed as 
SIGINT data standards. 

I I may eventually become a part of 

Project UTENSIL, the DDO Data Dictionary/ 
Directory that was envisioned by DDO managers 
in 1976. A task force, created under the lead- 
ership of the NDSC, drew up a charter for a 
dictionary that was to contain, data elements 
and their meanings; the directory was to give 
control functions, file names, etc. In the 
meantime, several DDO elements have proceeded 
to develop their own Data Dictionaries, unfor- 
tunately with little regard for standardization, 
so their terms are quite often incompatible 
with those for another DDO dictionary and some 
times even with their own particular group. 



In 1972 Harold Shaklee, then Chief of the 
NSA Data Standards Center, and George Hicken, 
COINS Project Manager, met. and agreed that the 
NSA Air Movements files in COINS would be 
standardized. On 7 September 1972 Mr. Shaklee 
convoked a meeting of a Working Group of 22 
people, most of whom represented the various 
Agency elements concerned with the appropriate 
files, f 



It is unfor tunate that those developing the 
I I files in the early days did not 

take the time to look into the work of others 
before building their own unique files. The 
trouble with that statement is that I know that 
exclusive files are being created right at thi'P . L 
moment and the lesson learned when the COINS EO 
users tried to query the | I files 

seems to have been wasted^ Some of those 
files are being built right within the same 
organization. 

And even th e limited progr ess we have seen 
in getting N the | I files in COINS 

standardized for NSA is tempered by the know- 
ledge that many other NSA files need work and 
we still have not attacked the problem of stan-\ 
dardization across the Community. In a 1976 



In Vol. II of the same study, on page 47, 
types of user problems are cited: 

"a. They must use different codes, 
acronyms and abbreviations fo^je^er^ , , 

encing like fields of information in ' 
different files. They experienfce ’ 
frustration both in framing interro- 
gations and in interpreting answers. 

"b. Users must cope with more than 
one set of data item codes for a 
common data element. 

"c. They must have access to a 
variety of working aids in preparing 
interrogations or in translating 
answers into meaningful information." 

In closing, I would just like to say that 
although the NSA Data Standards Center can be 
justifiably proud of its accomplishments in 
standardizing Data Elements within the Agency, 
we are all too aware of the fact that we have 
barely scratched the surface. 

The second point I would like to leave with 
you is that we covet your cooperation. If you 
don't work closely with us in the effort to 
reduce the data maze in the Agency, all our 
attempts to improve data standards will become 
little more than a treadmill operation -- no 
progress, but a lot of work just to keep abreast 
of the problem. 



. 86-36 
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BECHET 

LINGUISTICS 
AND THE CODE 
RECONSTRUCTOR 

STUART a BUCK, P 16 (Retf red ) 



L et me hasten co point out that I make 
no pretensions to more than a very 
limited knowledge of modern linguistic 
theory. It was my fate to be bom 
several decades too soon. By the time I entered 
college, language majors were expected to delve 
deeply into literature and history, but that 
was about it. Philology, as it was called 
then, was regarded as a field for specialists, 
not as a requirement for an AB in Romance Lan- 
guages. I remember once suggesting, rather 
timidly, that I would like to take a one- 
semester course in phonetics. My tutor knocked 
that one down quickly. Such an aberration, he 
pointed out, would conflict with a course on 
Voltaire, which would stay with me longer. He 
made it sound like a steak dinner. And so the 
advent of Bloomfield and his disciples caught 
me preoccupied, first with Voltaire, and then 
with the Great Depression, when it didn ! t seem 
to make any difference what kind of linguist 
you were -- everyone suffered equally. I can 
make one small claim to fame, however. Carl 
Darling Buck, the great philologist, and I are 
distantly related. Moreover, Carl Buck was 
Leonard Bloomfield’s teacher. That ought to 
count for something. I wish that I could set- 
tle for that, but total candor compels me to 
reveal that my learned relative and I share a 
common ancestor, one Colonel Jonathan Buck, who 
is reputed to have burned a witch back in the 
18th century. So much for name-dropping. . . 

I have mentioned all of this in order to 
explain why I was such a late-bloomer in the 
field of linguistics. It wasn’t until I ar- 
rived at Arlington Hall over 30 years ago that 



Stu Buck retired from NSA in 1973 but 
■returned to PI 6 several days a month as a 
reemployed annuitant to work on a special 
project requiring his unique qualifications . 
When he was finally debriefed at the con- 
clusion of that project in October 1977 , 
he handed over to a few coworkers copies 
of papers they might still find Useful. 
Among those papers was the tepsi of a talk 
Stu had given in September 1974* which is 
published here as sound words of advice 
for the next generation of people to 
carry out what Stu calls "one of the 
basic missions of the Agency 

Ed . 



I realized something was going on that ± 
very little about. After the war, I received 
some free benefits when my older brother decided 
to get his PhD in linguistics. He not only 
tested each theory on me, but passed on many of 
his textbooks, hoping that they would do me 
some good. In self-defense, I began to read 
through them. I started with Bloomfield -- and 
discovered that there was a whole new world 
waiting out there. Then I read Bloch and 
Trager, and found them informative, but not 
likeable. While this sort of desultory reading 
was going on, I became deeply involved in book- 
breaking -- or, to use a term that I prefer, 
code reconstruction . Before I retired in 1973, 

I had worked on a great variety of codes,] 

| I know that this sounds boastful, 

so I shall hasten to add that I still consider 
myself a novice in the field. I have seen a 
lot, but not all, of the elephant, so give me 
credit for being aware of that gloomy fact. 

One result of all this knocking around was that 
I acquired a compulsion to talk and write about 
my experiences, remembering that when I 
started out, no one told me anything. Not a 
word was uttered in my presence regarding tools, 
techniques, or standards. The implication was 
that either you could do it or you couldn’t -- 
it was just as simple as that. 

Plopped into Mu First Assignment 



Throughout most of my career, 1 have been a 
loner. On the few occasions when I have 
worked with another bookbreaker, I have dis- 
covered a curious reluctance on his or her part 
to talk about methodology. Usually it was a 
case of M That’s what it means because I say so” 
or "If you challenge my results, you attack me 
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as a person." After you have had your head 
bitten off a few times, you tend to be less 
talkative — unless you enjoy name-calling for 
its own sake. In my experience, the great ex- 
ception to this cantankerous type was Betty 
Doane. May she rest in peace! Betty was not 
only completely honest, but was not afraid to 
lay all her cards on the table. She never hid 
behind a mystique, and there was no chip on 
her shoulder as big as a plank. Everything 
was out in the open for all the world to see 
(those with proper clearances, I hasten to add). 
She was feisty, tough-minded, completely logi- 
cal in all of her arguments, and she never used 
arrogance as a shield for ignorance or insecu- 
rity. For that, I remember her with a special 
reverence. . . 
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Jk mong the leading attributes of COMINT, is fraught with potential disaster, as Brown* s 

#1 according to its past and present Bodyguard of Lies convincingly demonstrates, 

mLm practitioners, are the dual qualities of even to the most skeptical reader. Creditabili- 

f timeliness and authenticity. SIGINT ty is everywhere and at once a two-edged sword. 

support to tactical military commanders is con- 
tingent on these two characteristics, while a 
wealth of combat and peacetime applications 
have borne out this unique dependency on the in- 
telligence source known in the open literature 
as ’’intercepts. 1 ' Only recently, in the works 
of Kahn, Winterbotham, and Brown, has the public 
been told the story of the central, critical 
role played both by COMINT and by radio 
strategems in World War II and in the Allied 
victory. In fact, so consummately has this 
story been told that it is now necessar / to 
revise history in light of information only 
recently made available to scholars. Here we see 
journalists, and a former SSO, in the role of 
historical revisionists -- not a new role for 
journalists, but certainly a new role for 
SSOs, at least in the open literature. 

Dependency on SIGINT* s timeliness, authenti- 
city, and -- oft-times -- uniqueness is unset- 
tling. The quality of "believability” or 

creditability -- the much sought A1 source -- __ 
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FORMATTING PL/I SOURCE COPE 



/ BM f s Programming Language One (PL/ I) is 
an extremely large and complex higher- 
level language, even by the standards of 
programming languages being designed 
today. To the novice this language is pre- 
sented either in a watered-down version, sort 
of a "new style" of FORTRAN, or in such de- 
tail that the novice is quite easily over- 
whelmed. One would expect (as in fact is the 
case) that the compilers which process this 
complex source are themselves complex and they, 
too, are often presented in the same two ex- 
tremes to the inexperienced user. Either one 
uses with faith a set of mysterious "JCL" 
which has been passed around the office and 
takes for granted that this JCL is in some now- 
unknown sense optimal, or one obtains one of 
the compiler guides and attempts to wade through 
the wealth of information presented there. To 
aid the PL/ I programmer, two catalogued proce- 
dures have been developed which allow the 
programmer to maximize the amount of useful in- 
formation on the job listing and to have that 
information arranged and formatted in a highly 
readable way. These procedures have also been 
designed to be easily used: each requires only 
one JCL card. 

The PL/I Compilers 

Unlike most other higher- level languages, 

PL/I is supported by two distinct compilers. 

One compiler, the Checkout compiler provides 
.very detailed and elaborate diagnostics in ad- 
dition to, in some sense, acting as a PL/I 
interpreter. It is not too incorrect to con- 
sider that the Checkout compiler interprets 
PL/ I code, while checking subscript bounds for 
array references, string ranges for substring 
operators, the attempted use of uninitialized 
variables, etc., in addition to "trapping" 
many system-level errors (e.g., overflow or 
underflow, transmission errors, etc.) and pro- 
viding diagnostic information before the 
standard system action is taken. The facili- 
ties of the Checkout compiler can be invaluable 
for program development. 

The user, however, "pays" foT the extensive 
checking and debugging aids of the Checkout 
compiler in increased execution time. For this 
reason another compiler, the Optimizing com- 
piler, is used for the final compilation before 
the program is used in production. This com- 
piler attempts to optimize (either time-optimize 
or space-optimize) the resulting object module 
by eliminating both common and redundant ex- 
pressions, replacing in-line code for library 
function calls, and analyzing DO groups to al- 
low for optimal object coding for some special 
cases. The Optimizing compiler can substantial- 
ly reduce the execution time of a PL/I program 
compared to the old PL/I(F) compiler and, as 



PI 6 



was stated earlier, the Checkout compiler. It 
will not, however, check for certain types of 
user errors such as the use of uninitialized 
variables. It is precisely these types of er- 
rors that can return to haunt the programmer, 
or, more probably, the person now in charge of 
maintaining someone else’s old program with an 
unexplained abnormal termination after months 
of successful production use. The use of the 
Checkout compiler in program development can 
reduce the occurrence of such errors. 

KENSPL1 and KVRTSPL1 



A large number of compilation options exist 
for each compiler. These options vary from 
those that govern the amount and type of infor- 
mation on the job listing to those that deter- 
mine the amount of optimization to be done or 
debugging aids to be included. The proper use 
of these options will allow the user to get the 
most out of any particular debug run, or will 
allow the programmer who has to modify some old 
source code to understand the program logic as 
easily as possible. The catalogued procedure 
KENSPL1 1 does a PL/I compile, link-edit and 
execution using the Optimizing compiler, and 
KURTSPL1 2 does the same thing with the Checkout 
compiler. Both these procedures have been de- 
signed to be used by the novice, so that the 
following JCL is all that is required: 

//name JOB (standard JOB card) 

// EXEC KENSPL1 (or KURTSPL1) 



[PL/ I SOURCE] 



II 



So, in essence, the user need remember only 
one JCL card, the EXEC statement. 

KENSPLl^ formats the PL/ I source using the 
standard PL/I format conventions, e.g., DO 
groups and the THEN and ELSE clauses of IF ... 
THEN ... ELSE statements are indented, state- 
ment labels are highlighted, etc. Comments can 
be formatted in three different styles, all 
under the control of the individual programmer. 
The formatting of the entire source is done in 
a 100-column-wide section of the listing, al- 
lowing for complex PL/I statements to be listed, 
in one line. The block and DO-group nesting 
level prefaces each statement. Commonly used 
PL/I abbreviations (E.G., DCL, PROC, PTR, DEF, 



! KENSPL1 is named in honor of 
former Agency employee. 

2 Guess I 

3 Since both KENSPL1 and KURTSPL1 produce the 
same output, only KENSPL1 will be discussed 
from this point on. 
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etc.) are expanded for greater readability. 

The equal sign, when used as an assignment 
operator, is separated from the target and 
source variable by a blank. In addition one 
can use imbedded listing control statements 
(e.g., %SKIP, %N0PRINT, etc.). (Here, "imbed- 
ded" means occurring in the same source record 
as a regular PL/I statement.) Without 
KENS P LI this feature is not supported by the 
Optimizing compiler. 

This automatic formatting allows the logic 
of the program to be seen more easily both by the 
program designer and, more importantly, the pro- 
grammer in charge of program maintenance. It 
also frees the designer from the work of "hand- 
formatting" a source file and the person in 
charge of maintenance from the errors of any in- 
correct "hand-formatting." When this automatic 
formatting is used in conjunction with the DO 



| levels, the correct location of missing or mis- 
placed END statements can be quickly determined 
as well as some common program-design errors. 

An alphabetical list of all variables used in 
the program follows the source listing. For 
each variable, this list contains all the attri- 
butes of the variable, whether declared or as- 
sumed by default, and a list of each statement 
I (by statement number) where this variable is 
referenced. In addition a table of all the ar- 
rays and structures used in the program is 
listed along with information concerning the num- 
ber of dimensions, size and alignment in storage. 
To aid in debugging and hand-optimization, 
KURTSPL1 also produces a table listing the number 
of times each statement in the source was exe- 
cuted. An example showing the output of KENSPL1 
vs. the standard IBM procedure, PLIXCLG, is 
shown in Figs, la and lb. 



PL/I CHECKOUT COMPILER F IGURE_1_F0R_CRYPT0L0G * 



FORMATTED SOURCE LISTING 



STMT LEV NT 



1 0 F IGURE_I_F 0R_CR YPTOLOG * 

PROCEDURE OPTIONS ( MAIN) REORDER ) 



/* */ 

/« THE LISTING OF THIS PROCEDURE SHOWS SOME OF THE MAIN FEATURES OF KEMSPL1 «/ 

/* AND KURTSPLI. THIS PARTICULAR COMMENT IS AN EXAMPLE OF A FORMATTED. «/ 

/« CENTERED COMMENT. THIS TYPE OF COMMENT IS MEANT TO BE USED f6r GLOBAL. */ 

/* MAJOR COMMENTS. */ 

/* »/ 



2 1 0 DECLARE 

INPUT_RECORD CHAR <&0), 

'^J3UTPUT_ RECORD CHAR (100), 

EOF BIT (2) INITIAL ( * l * B ) , 

SPECIAL.CHARACTERS CHAR (2) INITIAL ('•?') I 

3 1 0 DECLARE 

DUPl EXTERNAL ENTRY ( CHAR (D VARYING, FIXED BINARY (3l,0>> RETURNS (CHAR (10) VARYING)) 

4 10 DECLARE 

LARGE FILE RECORD OUTPUT SEQUENTIAL ENVIRONMENT ( FB RECSIZE<I00) BLKStZE ( 1000) )l 

510 ON ENDFILE (SYSIN) 

EOF « *0* B ( 

6 10 GET_RECORDi 

DO WHILE (EOF)J 

7 I 1 READ F I L E ( SYSIN > INTO ( INPUT_RECORD ) 1 /* THIS IS A COMMENT INTENDED ONLY FOR THIS 

PARTICULAR LINE. NOTICE THAT IT IS FORMATTED TO APPEAR TO 
THE RI6HT OF THE PL/1 STATEMENT. */ 



8 1 1 

9 1 2 

10 1 2 

11 12 

12 1 2 

13 1 1 

14 l I 



IF ( SUBSTR ( INPUT_RECORD ,1,1) * ’ * I SUBSTR ( INPUT_RECORD , 80,1) - ' + *) THEN 
DO; 

OUTPUT_RECORD * INPUT_RECORD II DUPL ( SPEC I AL_CHARACTE RS , 9 ) II *4’ || * ') 
SUBSTR <SPECIAL_CHARACTERS ,2,1) * SUBSTR < INPUT_RECORD , 20. I ) J 
WRITE F I l E ( LARGE ) FROM ( OUTPUT_R ECORD ) J 
END) 

ELSE 

LEAVE GET_RECORD; 

END GET_RECORD; 



/* * EOF * HILL BE "1" ONLY IF THE "LEAVE" STATEMENT WAS EXECUTED. THIS IS THE THIRD TYPE OF COMMENT 
FORMATTING. */ 

15 1 0 IF EOF THEN 

CALL ERROR_ON_INPUT_FROM_SYSINi 

16 l 0 END FIGURE_I_FOR_CRYPTOLOG; 

Fig. la. Source listing using KENSPL1 
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